pwd: fix hostname resolution on macos #7029

reykjalin · 2025-04-08T04:09:06Z

Description

Yet another edge case in #2484

When macOS's "Private WiFi address" feature is enabled it'll change the hostname to a mac address. Mac addresses look like URIs with a hostname and port component, e.g. 12:34:56:78:90:12 where :12 looks like port 12. However, mac addresses use hex numbers and as such can also contain letters a through f. So, a mac address like ab:cd:ef:ab:cd:ef is valid, but will not be parsed as a URI, because :ef is not a valid port.

This commit attempts to fix that by checking if the hostname is a valid mac address when std.Uri.parse() fails and constructing a new std.Uri struct using that information.

It's not perfect, but is equally compliant with the URI spec as std.Uri currently is. Meaning not at all compliant 😅

Testing instructions

Unit tests

Important

I don't know if these tests are run in CI or if they're picked up by zig build test. I get an unrelated crash that mentions minidump and an invalid OSC command when I try to run zig build test on my mac.

Make sure zig test src/os/hostname.zig is passing.

Manual testing instructions

Setup - Enable the "Private WiFi address" setting

Important

You must be connected to WiFi to be able to test this.

Open your mac's "System Settings".
Go to Network → Wi-Fi → Details.

Set the "Private Wi-Fi address" setting to Rotating.

Important

Now you wait. The private Wi-Fi address will eventually rotate to a mac address that ends with a non-digit, e.g. 0a, ff, e2, etc. You'll notice this when your shell integration stops working, e.g. you open a new tab in Ghostty and the shell is in your home directory instead of whichever directory you had open in your previous tab.

Testing the changes

Open Ghostty.
cd to any directory that isn't the default (usually $HOME) directory, e.g. cd Documents.
Open a new tab (Cmd+T) or split (Cmd+D).
Assuming the setup steps have been followed you should:
- On main: land in $HOME in the new tab or split.
- On this branch: land in the same working directory as the original tab or split.

jparise

Two quick thoughts:

This is probably getting complicated enough to warrant a separate utility function (with tests), perhaps outside of the stream handler.
I'm starting to feel like we should follow Kitty's example and treat the file:// and kitty-report-cwd:// schemes differently: only file:// URLs get the encoding. (See #7033)

reykjalin · 2025-04-08T15:52:54Z

This is probably getting complicated enough to warrant a separate utility function (with tests), perhaps outside of the stream handler.

100% agree, I had the same thought as I was working on this. I haven't confirmed the fix though so I figured I'd make a quick and dirty version that I could test, and clean it up later. And yep, that includes a separate function, tests, the whole thing 🙂

I'm starting to feel like we should follow Kitty's example and treat the file:// and kitty-report-cwd:// schemes differently: only file:// URLs get the encoding.

Yeah, we probably should. Or at the very least we probably shouldn't be using std.Uri here. It's such an incomplete implementation at this point that we'd probably be better served making our own parser here 🤔

For example, percent_encoding isn't actually enforced in std.Uri, it just assumes it. There's no escaping or cleaning done to the path to make sure it's safe, etc. That shouldn't necessarily be part of std.Uri, but I think those are things we should be doing here, so we'll want our own parser here eventually anyway 🤔

jcollie · 2025-04-08T16:23:54Z

It seems to me that this would be better solved on the macOS level. Either by using scutil to force a "real" hostname or modifying the shell integration to inject a better hostname into the OSC 7 escape.

reykjalin · 2025-04-09T21:07:27Z

It seems to me that this would be better solved on the macOS level. Either by using scutil to force a "real" hostname or modifying the shell integration to inject a better hostname into the OSC 7 escape.

I think the main problem is that posix.gethostname() - the hostname we compare to whatever the shell integration passes to us - returns the mac address version of the hostname.

I suppose we could run scutil --get LocalHostName on macOS instead of calling posix.gethostname() and make sure the shell integration is getting a similar value for us to compare 🤔
But it also feels really bad to have to run an external executable on macOS to get this working right.

And either way I think we should treat mac addresses as valid hostnames, even if they're not compliant with the general linux hostname spec of [a-z0-9] and a hyphen (-) due to using colons (:). This feature is enabled by default in macOS, and it isn't that big of a lift to support specifically only valid mac addresses, even if it does complicate this particular part of the codebase somewhat.

reykjalin · 2025-05-01T03:29:58Z

Finally got to a place where I can reproduce it and recorded a video just to demonstrate:

ghostty-bug.mp4

reykjalin · 2025-05-01T04:27:57Z

And now to demonstrate that the current set of changes work:

ghostty-fix.mp4

reykjalin · 2025-05-01T04:32:11Z

I still need to clean up the code here more before this is ready. I'm thinking of creating some sort of utility function in src/os/hostname.zig that will extract a hostname from a file url string passed to it. We can then add some tests for that function so we can be sure we're doing this right.

It's way too late here to do that now though, so I'll pick this up again when I have the time, hopefully in the next week or so.

reykjalin · 2025-05-09T03:03:01Z

@jparise I think this is ready for a proper review now :)

src/os/hostname.zig

jparise

Looks good to me but deferring to others who have more regular maintainership over these files.

src/os/hostname.zig

When macOS's "Private WiFi address" feature is enabled it'll change the hostname to a mac address. Mac addresses look like URIs with a hostname and port component, e.g. 12:34:56:78:90:12 where `:12` looks like port 12. However, mac addresses can also contain letters a through f, so a valid mac address like ab:cd:ef:ab:cd:ef is valid, but will not be parsed as a URI, because `:ef` is not a valid port. This commit attempts to fix that by checking if the hostname is a valid mac address when `std.Uri.parse()` fails and constructing a new std.Uri struct using that information. It's not perfect, but is equally compliant with the URI spec as std.Uri currently is.

Also adds a test to verify that the function is working as intended.

we only need the mac-address-as-hostname workaround on macos, so we now have a comptime check to see if we're on macos.

reykjalin · 2025-06-08T02:20:06Z

Sorry for the long response time here. I've rebased the branch on main and addressed the previous review, so this should be ready for another review 🎉

src/os/hostname.zig

reykjalin · 2025-06-14T20:29:46Z

src/os/hostname.zig

+    return std.Uri.parse(url) catch |e| {
+        // The mac-address-as-hostname issue is specific to macOS so we just return an error if we
+        // hit it on other platforms.
+        if (comptime builtin.os.tag != .macos) return e;


@jparise I changed this from comptime if (… to if (comptime … to fix the build failure on non macOS systems, but I'm not familiar enough with Zig's comptime to know if it makes sense to even keep the comptime check in here? Should we just remove it, or does it still make sense to keep it? 🤔

In its current state, I don't think we need to gate this on macOS. It's done in a generic way, although it would be good to get some real-world confirmation that this all makes sense on other platforms (e.g. no false positives/negatives).

I did a very simple test run in a Fedora VM and this seemed to be working correctly. It was the same thing I did in #7029 (comment) to confirm this was was working correctly. Super simple test so I'm not sure if we want something more thorough.

Anything I can do here to help with testing this on other platforms?

@jcollie and @pluiedev, do you have any opinions on how this will play on Linux?

Absolutely no clue

jparise reviewed Apr 8, 2025

View reviewed changes

reykjalin force-pushed the fix-invalid-uri-in-hostname-on-macos branch from d372a1f to a3c7b3f Compare May 1, 2025 03:58

reykjalin force-pushed the fix-invalid-uri-in-hostname-on-macos branch from b780820 to f6d1718 Compare May 9, 2025 02:53

reykjalin requested a review from jparise May 9, 2025 03:02

reykjalin marked this pull request as ready for review May 9, 2025 03:02

00-kat added the os/macos label May 9, 2025

jparise reviewed May 10, 2025

View reviewed changes

src/os/hostname.zig Outdated Show resolved Hide resolved

src/os/hostname.zig Outdated Show resolved Hide resolved

src/os/hostname.zig Outdated Show resolved Hide resolved

src/os/hostname.zig Show resolved Hide resolved

src/os/hostname.zig Outdated Show resolved Hide resolved

reykjalin requested a review from jparise May 14, 2025 03:44

jparise reviewed May 16, 2025

View reviewed changes

src/os/hostname.zig Outdated Show resolved Hide resolved

src/os/hostname.zig Outdated Show resolved Hide resolved

src/os/hostname.zig Show resolved Hide resolved

reykjalin added 13 commits June 7, 2025 22:07

Fix modulo operation and custom Uri struct init

19ca1bf

extract mac address validity check to function

b66368b

take kitty-shell-cwd scheme into account

64bfaf2

extract url parsing into its own function

ffe7f0d

Move url parsing helper to os/hostname

e0655a7

Also adds a test to verify that the function is working as intended.

use iterator syntax in for loop

7a639a7

don't rely on hard-coded schemes

bb07e9c

re-order end-of-hostname validity check

a24d0c9

add tests for hostnames without a path component

dfdb588

name the 17 magic constant mac_address_length

68f48b9

add comptime check for platform

7760389

we only need the mac-address-as-hostname workaround on macos, so we now have a comptime check to see if we're on macos.

use explicit error set

e4a175d

reykjalin force-pushed the fix-invalid-uri-in-hostname-on-macos branch from d6b99a6 to e4a175d Compare June 8, 2025 02:07

reykjalin added 2 commits June 7, 2025 22:12

merge std.Uri.ParseError and os/hostname error sets

73e5f7e

move mac address length constant to file-level scope

6ed94b0

reykjalin requested a review from jparise June 8, 2025 02:19

jparise approved these changes Jun 10, 2025

View reviewed changes

src/os/hostname.zig Outdated Show resolved Hide resolved

use else if instead of else { if }

31e386a

reykjalin requested a review from jparise June 13, 2025 15:20

jparise approved these changes Jun 13, 2025

View reviewed changes

fix comptime if statement

2f33eee

reykjalin commented Jun 14, 2025

View reviewed changes

reykjalin requested a review from jparise June 18, 2025 16:45

mitchellh merged commit 0b5092b into ghostty-org:main Jun 24, 2025
38 checks passed

github-actions bot added this to the 1.2.0 milestone Jun 24, 2025

jparise mentioned this pull request Jul 4, 2025

Add SSH Integration Configuration Option #7608

Merged

pwd: fix hostname resolution on macos #7029

pwd: fix hostname resolution on macos #7029

Uh oh!

Conversation

reykjalin commented Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing instructions

Unit tests

Manual testing instructions

Setup - Enable the "Private WiFi address" setting

Testing the changes

Uh oh!

jparise left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reykjalin commented Apr 8, 2025

Uh oh!

jcollie commented Apr 8, 2025

Uh oh!

reykjalin commented Apr 9, 2025

Uh oh!

reykjalin commented May 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

reykjalin commented May 1, 2025

Uh oh!

reykjalin commented May 1, 2025

Uh oh!

reykjalin commented May 9, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jparise left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

reykjalin commented Jun 8, 2025

Uh oh!

Uh oh!

reykjalin Jun 14, 2025

Choose a reason for hiding this comment

Uh oh!

jparise Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

reykjalin Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

jparise Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

pluiedev Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

reykjalin commented Apr 8, 2025 •

edited

Loading

jparise left a comment •

edited

Loading

reykjalin commented May 1, 2025 •

edited

Loading